All too frequently application programs experience incidents which result in the loss of information, forcing users to perform the frustrating and inefficient task of re-entering all of the lost information into the application program. Additional inefficiency is created by the need to restart the application program or even the computing device itself in an attempt to recover from the incident, or to attempt to prevent further incidents. Unfortunately, the vast majority of users are ill equipped to determine why the incident occurred, and are therefore generally powerless to prevent its reoccurrence.
The programmers of the application programs, and others tasked with supporting the programs after their release, are often in a worse position to assess the causes of various incidents because users either cannot adequately describe the circumstances under which those incidents occurred, or do not even bother to report them. Consequently, many programmers and application support personnel are not even aware of the majority of such incidents and, of those incidents of which they are aware, they do not possess sufficient information upon which to provide useful feedback. Additionally, because many users do not bother to report such incidents, the application support personnel often underestimate the existence of the applications' faults, or receive an insufficient quantity of user reports from which to detect similarities among the incidents and thereby attempt to resolve them.
To address such shortcomings, modern operating systems have recently begun to incorporate a rudimentary incident reporting mechanism by which a small, pre-selected amount of data is saved when an incident occurs, and then subsequently data is transmitted to a central repository which can be accessed by programmers and other support personnel so that they may attempt to ascertain a cause, and provide a solution to prevent further incidents. Unfortunately, such incident reporting mechanisms are often too general to provide useful information regarding the incidents of particular applications. For example, an incident reporting mechanism that detects an application incident where the application stops responding, commonly referred to as a “hang”, may collect data from an area of memory that the operating system believes is most relevant. However, the programmers and support personnel of that particular application may not learn anything useful from the saved data, and might have preferred to save a different collection of data, which may have provided more useful information. Of course, the above assumes that the programmers and support personnel of that particular application would even seek to obtain the data collected by the operating system. Generally, such information is reported to the support personnel supporting the operating system, and there may exist inefficiencies of communication between the operating system support personnel and the application support personnel.
Therefore, what is needed is a mechanism by which application developers, programmers and support personnel can specify which information is collected from their applications in the case of particular incidents. In addition, the developers and programmers should be provided with default mechanisms which can collect a minimum of information to record those incidents that may not have been foreseen by the developers and programmers of the application, or which may be the result of an interaction between the applications of two or more different groups of developers and programmers.